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Synchronising databases in stacked network units 



(57) In a stack of multi-port network communication units each unit has a forwarding database, the units are 
connected by way of a cascade, and at least some of the units are connected to links constituting a trunk. 
When a unicast data packet is received at a first of said units and the unicast data packet has a destination 
address which is not the subject of an entry in the forwarding database of the first unit, the unicast data packet 
is sent by way of the cascade to the other units in the stack, accompanied by a flag. When a second unit has in 
its forwarding database an entry, associating the destination address with forwarding data, it sends a 
management packet indicating said destination address and the identity of said second unit, so that the 
database of the first unit can be immediately updated. 
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METHOD FOR SYNCHRONISING DATABASES IN STACKED NETWORK UNITS 
Field of the Invention 

5 This invention relates to the management of forwarding databases in a cascaded stack of 

network units, particularly multi-port switches, in a packet-based data communication system 
which employs addressed data packets. The invention particularly relates to the reduction of 
unnecessary traffic flow constituted by the broadcast or 'flooding' of packets having 
unknown destination MAC (media access control) addresses. 

10 

Background to the Invention 

Packet-based data communication systems, such as Ethernet systems, commonly employ- 
address data packets (otherwise called frames) which include source and destination media 

15 access control addresses as well as, usually, other type, control and address data, such as 

network address or IP address data. Data of this character normally precedes the payload or 
message data of a packet. The MAC address data in such a packet defines, in media access 
control or Mayer T terms, the device from which a packet has come and to which a packet 
should be sent. There are various forms of packet including 'multicast' packets, which have 

20 an address specifying a group of destination devices, and 'broadcast 1 packets, which should 

be sent to all possible destinations. Excessive broadcasting of packets is limited by the 
segmentation of a network into, for example, virtual local area networks, and it is common for 
packets to contain an identification of the virtual VLAN on which they originate. 

25 Notwithstanding the variety of packets, the present invention will be particularly concerned 

with ; unicasr packets. If such a packet is received by a network unit, it is usually subject to a 
look-up in a database. Such a database, normally called 'forwarding database 5 , contains 
destination addresses with forwarding data, such as port numbers, and other data. Different 
forms of forwarding databases, including those which can be looked up by means of media 



access control addresses and network (IP, addresses are known Vartous merhods of look-up 
are also known in the literature 

Broad ly . a forwarding database may be compiled by reading the source MAC addresses of 
mcommg dara packers and. if such source address is no, in the database the entry of tha, 
source address can be made together with irrelevant forwarding data, for example the port on 
winch tha, packet was received. Then, when a packet is received having a destination address 
whtch matches an entry in the table, the packer can be sen, ,o ,ha, destination address defined 
by ,he forwarding da.a in ,'he da,a entry „ is also known ,o add entries in such a da.abase bv 
means of management- frames, particularly when a network is initially set up. 

If a unit receives a packet which has an -unknown' destination address, tha, is to say an 
address which is no, the subject of an entry in the table. ,, is usual ,o flood' the packer tha, is 
.0 say to send it to all the possible pons of the urn, This is a preliminary to an address 
resolut.on protocol' wherein when such a flooded packet is rece.ved from a device which has 
a network address corresponding to the address in ,he packet i, will reply and the relevant 
destmanon address can be entered inro the da.abase for subsequen, use in relation ,o packets 
intended for the destination. 



Stacked Units 



A feature of modern network practtce is 'stacking' of units such as switches so as to form in 
effect a single entity. Switches which are similar or a, leasr comparible may be connected 
together, as explained later, so tha, for example four swuches having, for example. 24 pes 
each may behave as a single 96-por, swttch The term stackaWe' is a convenrional ,erm in 
these crcumstances. It is cusromary ,o stack the units physically one on top of the other bu, 
the term ,s tmended to relate to the functional relationship between them 
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Cascades 

A group of stacked units requires a means of communication which is generally termed a 
5 'cascade' A cascade is connected to at least one port on each unit and provides in effect a 

communication ring by means of which a packet which leaves a unit by way of a port (termed 
a cascade port) connected to the ring can reach all the other units by way of the ring. Cascades 
normally include a variety of control mechanisms which enable a given unit to determine the 
unit by which a packet was placed on the cascade, mechanisms to prevent circulation of 
lo packets continuously on the ring and so on. Cascades are known in a variety of forms. 

Examples are: 

Trunking 

15 A further known feature in network practice relevant to the invention is 'trunking', which is 

described in for example WO99/29072 and GB-2333429. The term is used to describe a 
communication link which essentially comprises a multiplicity of links from a device or 
group of devices to another device or group. In its simplest form it is constituted by a 
multiplicity of links each to a respective port on a single unit from a single source entity; a 

20 typical feature is that traffic intended for a particular destination may arrive at any of the links 

constituting the trunk. Trunking is known to be useful in order to increase the bandwidth 
available for traffic from a particular source or going to a particular destination. 

It is generally desirable in order to provide appropriate versatility in network connections, to 
25 allow the connection of the links constituting the trunk to different pons not only on the same 

network unit such as a switch but also to pons on different units of a stack. Such a trunk may 
be termed a stack- wide trunk* It is not necessary for all the units in a stack to have a port 
which is a * member' of the trunk. Our recent patent applications numbers 0004517.9 filed 28 
February 2000 and 0010032.1 filed 26 April 2000 describe various proposals for the specific 
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forwarding rules 
Summary of the Invention 



The present invention rela.es specifically ,o a problem arising from excessive floodin. of 
packers conrain,,,, mkmm , unicast MAf ^ ^ ^ 

arc stacked rogerher. ,, , norma, pracice ro nood such addresses ou. on a„ pons of rhe s,ack 
Thus ,f a en uni , ,„ the s , ack receive$ m Me Qf . s a packa ^ ^ 

MAC address „ no, rhe subjec, of an e„,^ ,„ its foroarding da , abase , he ^ ^ on|y 
flood * a, pace, on, on al, ,he pons (or a, ieas, all rhose pons for which such floodino is 

,he o„,er u„,,s in ,he srac, so as ,o be flooded from a„ rhe reievan, pons Ahhough mis 
flooding causes a .emporary and inevitable degradation in bandwidth and performance of ,hc 
ncrwoflc, eve„,ua„ y a response fron, the desrination MAC address ,„ q „es„on wifl cause ,ha, 
a dress ,o be learned', rha, ,s ,o say made ,he subjecr of an en.ry ,„ ,be forwards da.abase 
c» a., ,he unus ,„ ,he stack Then whetber a „„,, rece i V es a packet containing tbl, sp eeifi c 
destination MAC address by way of one of its pons directly or by way of the cascade no 
flooding w,„ occur subse q uen„y whiie the des,,„a,ion MAC address remains in ,he database 
Howeve, ,„ a networlc sysrem wbere there is a stack-wide .run,, a response from a remo.e 
de ice wbic would resoive tha, unknown des.ination address win be sen, ,„ one of the units 
s.ack but need no, necessary reach a„ the orher units of ,he stack. More pan,cu,ar,y 
he response which would enable resolution of the unknown destination MAC address may be 
sen by the receiving uni, back along the trunk by way of a different Hnk ,o that on which the 
packer was originally received. 

This problem can be a„ev,a,ed a, presen, by means of separate flagged storage of unknown 
u , as, destmanon MAC addresses More panicu,ar,y. if, uni, receives an unknown umcas, 
destination MAC address, i, will save die destination MAC address in a distinctive manner 



for example in a separate area in memory or with a special flag. The stack of units may be 
controlled by stack-wide software, which polls each unit to determine whether any of the 
units have received any unknown unicast MAC addresses and has recourse to the forwarding 
databases of all the units to resolve the unknown unicast destination MAC addresses for all 
- s the units However, such a solution is generally slow and is limited by the size of the storaue 

available and the speed at which the software can be permitted to poll all units on the stack. 
More particularly polling of units will require bandwidth on the cascade which is then not 
available for ordinary traffic flow. 

to The present invention is based on the transmission of a packet which has an unknown unicast 

MAC destination address on the cascade with a flag, which may be constituted by a single bit, 
to indicate that the destination address is unknown. Such a flag may be constituted by 
otherwise redundant field space in the header of the packet, for example a VLAN tag header 
as described later. All the units on the cascade will receive the flagged packet and if any unit 

15 already has that MAC address in its database, it will produce a management frame which is 

sent on the cascade indicating to the other units of the stack the location of the unknown 
MAC address. This allows all units on the stack to learn' that destination MAC address, i.e. 
make it the subject of an entry in its forwarding database, the entry including appropriate 
forwarding data for that destination address. 

20 

Further features of the invention will be apparent from the following description with respect 
to the accompanying drawings. 

Brief Description of the Drawings 

25 

Figure 1 illustrates a switch having a multiplicity of ports for receiving and forwarding data 
packets and other generally conventional features. 



Figure 2 ifiustrates a stack of units connected by a cascade and having a trunk connection to 
some of the units in the stack. 

Figure 3 illustrates an operational phase of the stack shown in Figure 2. 
F.gure 4 illustrates another phase of operation of the stack. 
Figure 5 is a further phase of operation of the stack 

Figure 6 is a flow diagram illustrating the production of a flag for an unknown unicast packet 

Figure 7 is a flow diagram illustrating the operation of units which receive a flagged packet 

Figure 8 illustrates an Ethernet packet in a typical form. 

Figure 9 illustrates a method of flagging such a packet. 

F.gure 10 illustrates a specific routine for placing a flag on a packet. 

Figure 1 1 illustrates the response of a unit to a special management packet. 

Figure 12 schematically illustrates a spec.al management packet. 

Detailed Description 

F.gure I iUusrrares ,„ a deliberately simplified way a multi-pot, switch for a packet-based 
data communication system. The switch 10 may in general have , substaMia| ^ of 
ports, such as twenty-four or even many more, bu, in the present example is shown as havi„« 
four pons I. 2. 3 and 4 Each of these pons is associated w.,h a 'Pot, ASIC la - *I 
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respectively These port ASICs provide the customary processing of packets after they have 
received and before they are subject to the look-up and forwarding process. Very typically, 
the port ASICs may be constituted on a single integrated circuit along with most of the other 
components of the switch, with the possible exception of some of the memory 5, but it is not 

5 intended to limit the present invention to any particular hardware implementation or 

configuration. Generally, packets received by any of the ports may, after temporary storage in 
FIFOs schematically represented as lb to 4b for each of the ports, will be stored in memory 5 
while address data in the packets is examined to find matches of destination addresses in a 
forwarding database 6. As previously mentioned, this type of forwarding database may be 

10 compiled by an examination of source MAC addresses in incoming packets in a manner 

which is well known in the art. The switch has a bus system 7, shown as a single bus line 
merely for convenience, and a switching engine S associated with a look-up engine 9. These 
may be constituted by a single software or hardware controlled entity which has recourse to 
the forwarding database 6 as well as providing control of the memory 5. Again, as is well 

15 known in the art, the look-up engine 9 (called herein 'forwarding engine 1 ) will perform look- 

ups in the forwarding database 6 and the combined entity of switching engine 8 and look-up 
engine 9 will cause entries in the database as well as retrieval of packets from memory 5 so 
that packets can be forwarded to the port or ports indicated by the nature of the address data. 
For the sake of completeness the switch 10 is shown as including registers 11 which store 

20 configuration data for the switching and look-up engines. 

It is known to insert entries in a forwarding database such as database 6 by means of external 
control exerted by management packets. This may be necessary when initially configuring the 
switch or for other purposes. 

25 

Figure 2 illustrates one form of stack-wide trunk to which the invention particularly relates In 
this example there are four switch units, denoted Unit 1 to Unit 4, which are connected by- 
way of a cascade 20 which may be in any of the forms previously described. There is a 
remote device A, which is connected to the stack by means of two communication links 21 
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relevant ports in the stack. However, when sending the packet down the cascade it also sends 
a flag, herein called 'unknown unicast DA flag' with the packet indicating that the 
destination MAC address of the packet was unknown when it was received by unit I. A 
possible way of inserting this flag is described later. All units on the cascade receive the 
5 packet and check the status of the flag. If any unit already has in its database the MAC 

destination address of B. and the unknown unicast DA flag is set then it must take action. 

Figure 3 indicates that Unit 4 is the unit which will take action because it has device B 
connected to one of its local pons. In accordance with the invention and as shown in Figure 4, 
in Unit 4 will send a special management packet back up the cascade indicating (in a manner 

described later) to the other units in the stack that it has the relevant forwarding data for that 
unknown MAC address. This allows all units on the stack to learn the location of that MAC 
address. Thus there is no longer a need to flood packets to all units on the stack. 

15 Figure 5 illustrates the subsequent phase wherein packets received by Unit 1 by way of the 

trunk from device A and intended for device B will be sent only by way of the cascade to 
device B. 

Fi°ure 6 is a flow diagram showing the initial phase. Unit 1 will perform a look-up, stage 60, 
2o in its forwarding database to determine (stage 61) whether the destination address of a packet 

is known. If the destination address is not known then the unknown unicast DA bit will be 
sent down the cascade with the packet (stage 62). 

Figure 7 illustrates the operation of the receiving units (i.e. Units 2 to 4 in this example). They 
25 parse a received packet (stage 71). If there is detection of an unknown unicast destination 

address (stage 72), the relevant forwarding engine will determine (stage 73) whether the 
destination address is known locally (i.e. whether it is in the database of the receiving unit). If 
it is known, then this unit will construct (stage 74) a management packet to respond with 
destination of unknown destination address. 



♦ 1(1 - 



Ftgure 8 „ a d , agram of a „ E „, ernel ^ 

address (DA) and a 48-bit source address (SA> The ra H , a "°" 

address data bu, for si,n pI icirv this add „ '"''^ 3 > 

within the data' , s / " ^ ™> « as included 

« ; p :::r r na,ure ,o — a — 

CP, bu and a "VLAN 1D , „ , Z^^^X^' ^ ^ ' 
Preceded by a VLAN tag header. k „ow„ as ,he 8,00 I " 0 " ^ '° * 

■■ is possible Ulilise , he [ag head£r fidd _ o convey jnfomaijon 

pac.ce, ,0 ,„ Fisure o. the field comai „ s a firs , ^ ° : p e : a ™^' ; — * - 
original pace, had a VLAN identification field and 5 „ « w ch ' ""^ "* 

—on. such as ,he ,„ kn0 w„ delation address ^ 

:r n t ,as header is - - 

identification field or », FrL ^ "** ' ™ 

not. From a star, stage (101) which depends on stage V of Figure 6 

defined i„f orraatio , The mos , ^ ^ f £ JLAN rag wtth , he user 

came with the VLAN ,„ and so the las, 16 h , ' ,hi " 

(for the sake of an «. """""^ 3 Va " d *** Bi,s 30 -'° -elude 

or tne sake of an example) an identification number for th» ,n,„L j •, 
for the original uni , such as "** fa *** a " 'Oent.fication number 

-ining bus. bus 1 ,0. are unclad ^ deS "" a,i ° n ^ f ^ 

of' ; z:r t r d - ,hen s,ase ■ 04 is ~ ™* — - — 

packet ,n the posttton that would normally be occupied by a VLAN rao 



The most significant bit, bit 31, would be set to zero to indicate that the packet did not come 
in with the VLAN tag. Bits 30-16 are determined in the same way as bits 30-16 in stage 103. 
The remaining bits, bits 15-0. which would normally contain the VLAN ID, CFI and priority 
bits for the packet may be set to some default values. 

Whichever of the stages 103 or 104 is performed, the packet is transmitted down the cascade. 
When the packet ultimately leaves the stack of units, the most significant bit of the substituted 
VLAN header tag will determine whether the ordinary tag field (as shown in Figure 8) is to be 
re-inserted or the whole 32 bits of the VLAN tag are to be removed from the packet before it 
finally leaves the system constituted by the stack of units. 

Figure 1 1 illustrates the process performed in a unit in response to a special management 
packet received on its cascade port (or one of its cascade ports if more than one is connected 
to the cascade). 

From a start stage 111, there is a determination whether a special management packet has 
been received on the cascade port. This stage (stage 112) and the next stage may be 
performed by a MAC device within the relevant port ASIC (see Figure 1). Stage 113 
indicates that if the special management packet is detected, it is parsed for the N4AC address 
defined within it, as well as (preferably) a VLAN identification as well as a 'box ID' field. 
The latter is an identification of the unit which has originated the special management packet. 

The parsing of the packet provides commands for (as shown by stage 1 14) the relevant fields 
can be entered into the forwarding database. The forwarding data for that destination address 
is preferably the cascade port on which the management packet was received. In this way 
when, for example, Unit 1 is shown in Figure 5 receives a subsequent packet having the 
previously unknown destination MAC address, it will have sufficient forwarding data 
associated with the entry in the forwarding database to be able to forward such a packet only 
to the cascade, as shown in Figure 5. 
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Claims 

1. A method of operating a stack of multi-port network communication units each of which 
has a forwarding database, the units being connected by way of a cascade, and at least some 

5 of the units being connected to links constituting a trunk, the method comprising: 

receiving by way of the trunk a unicast data packet at a first of said units, 

sending, when said unicast data packet has a destination address which is not the subject of an 
10 entry in the forwarding database of the first unit, said unicast data packet by way of the 

cascade to the other units in the stack, accompanied by a flag denoting the absence of said 
entry; 

sending, for a second unit in the stack, when said second unit has an entry in its forwarding 
15 database, associating said destination address with forwarding data, a management packet 

indicating said destination address and the identity of said second unit; and 

in response to said management packet, making in the forwarding database of said first unit 
an entry relating the said destination address and said identity of said second unit. 

20 

2. A method according to claim 1 wherein the flag comprises a field in a header of the 
unicast packet as it is sent on the casacade. 

3. A method according to claim 1 or claim 2 wherein said address is a media access control 
25 (MAC) address 

4. A multiport network switch for data packets which include media access control addresses, 
the switch including a forwarding database for relating destination MAC addresses to 
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